Handle both problems with a field. A field ultimately has a text label (or not) and is not compiled into MET files and therefore is dynamic.
In Studio, specify one field for each possible signature — each using a different signature font. All the fields could be defined to occupy the same space and, because only one will trigger, it should not cause a problem.
For instance, here is an example that would yield a mutually exclusive result.
;0;0;HEADERREC;1;46;SIGNATURE;0;46;;hardexst;11,HEADER,15,TBS ABCD;N;N;N;N;6379;8265;12012;
;0;0;HEADERREC;1;46;SIGNATURE;0;46;;hardexst;11,HEADER,15,TRJ ABCD;N;N;N;N;6379;8265;12013;
;0;0;HEADERREC;1;46;SIGNATURE;0;46;;hardexst;11,HEADER,15,JSN ABCD;N;N;N;N;6379;8265;12015;
Except for the font ID at the end of each line and the search mask criteria, these lines are identical. Notice that each line specifies the same destination field name. Although this is permissible, it is sometimes difficult to maintain in the Field Database Editor. For clarity and ease of maintenance, give each field a different name.
This example uses the HardExst rule. This rule checks for the existence of a specific text string occurring at a specific location. If found, the subsequent text is hard-coded into the field. In this case, assume that each signature only takes the characters ABCD to print. If one required more or less letters or different letters, you would change this.
You could use a different rule, such as the IF rule, and try to handle all cases in a single DAL script, but this may be more difficult for some people and harder to debug if the correct results were not yielded.
You could also write a custom field rule and change the font ID yourself.
© Copyright 2018, Oracle and/or its affiliates. All rights reserved. Legal notices.